Modular information handling systems such as chassis-based platforms and network switches provide organizations with flexibility to expand capacity and add capabilities as the need arises and to customize according to the needs and preferences of the organization. A chassis includes a number of slots into which various types of modules including various types of line cards, power supply modules, cooling fan modules, processing modules, and so forth may be inserted. A user or administrator can configure a chassis for any number of specific uses by inserting the appropriate modules and setting the appropriate configuration options.
For networking devices, module reusability has been an integral part of bringing new products to the market quickly. For instance, power supply units (PSUs) and fan trays can be interchangeably used between the S4810, S4820, S4840 and S5000 networking switch platforms as provided by Dell, Inc. of Round Rock, Tex. For chassis-based platforms, there are designated slots for specific functional modules such as supervisor cards, port cards, service modules, and so forth. Historically, methods like mechanical slot-key and silk-screen symbols were used to indicate modules supported in the system. This technique, however, fails when a module's compatibility is dependent on what other modules are present in the system.
Use of static module compatibility methods are a major inconvenience at best and at worst can lead to equipment damage, loss of data, loss of efficiency, business disruptions, and increased operating costs. For example, if an incompatible module is inserted in the system, the user has to wait for the system to detect the card, analyze its supportability and provide feedback to the user via a console/syslog. This whole process may take several minutes. In a data center in which there are tens, hundreds, or many thousands of devices, the cumulative time spent diagnosing compatibility issues can span many hours.
Even if a module is supported by the system, there are instances in which it could be incompatible due to the current configuration of the system. For example, in the S5000 platform, fan trays are allowed only in certain slots due to thermal and airflow requirements. If a system has fan trays with a forward airflow profile, inserting a reverse airflow fan tray may be incompatible with the current configuration even though reverse airflow fan trays are supported by the system.
As another example, in some chassis, a certain flavor of an input/output (TOM) module is allowed with following restrictions: if no other IOM is present, any IOM is allowed; if a high-end IOM is present in a slot, no low-end IOM is allowed in adjacent slots. If a low-end IOM is present in a slot, no high-end IOM is allowed in adjacent slots.
As another example, if pre-provisioning is supported (i.e., specific slots are pre-configured for specific module), inserting an unexpected module, albeit supported, will cause a major churn in the processing of that module.
Based on the restrictions discussed above and others, there is a need for providing a dynamic module compatibility detection technique that can not only determine if a card is supported in the system on a given slot but also have the capability to determine the module's compatibility based on the current configuration of the system.
The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.